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REMARKS/ARGUMENTS 

1 . Amendments to Claims 

Claims 6 and 13 have been amended to include the limitations of claims 7 and 

11. 

As a result, amended claims 6 and 13 now recite that the software module to be 
transferred is in the form of DTM and the operating program serves as an FDT-frame 
application, as described in the first paragraph on page 5 of the original English 
specification. 

In addition, claims amended 6 and 13 now also recite checking the authenticity 
of the software module by a function block shell. 

In addition to combining claims, claims 6 and 1 3 have been amended to explicitly 
recite that the function block shell is in the field device, as described for example in the 
third complete paragraph of the original specification ("In a further development of the 
invention, a shell application is installed in the field device. . .") as well as the paragraph 
bridging pages 5 and 6 of the original specification (" For executing software code in the 
field device F1, a function-block shell with associated interfaces S1', S2' is provided'). 

Because the amendments combine original claims, and/or are supported by the 
original specification, it is respectfully submitted that the amendments do not involve 
"new matter," and entry of the amendments is accordingly requested. 

2. Rejection of Claims 6 and 8-10 Under 35 USC 5103(a) in view of U.S. Patent 
Publication Nos. 2002/0077711 (Nixon) and 2005/0033886 (Grittke) 

This rejection has been rendered moot by the amendment of claim 6 to 

include the limitations of claims 7 and 1 1 . 
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It is noted that claim 1 1 appears to have been included in this rejection, as 
set forth on page 9, even though it is not mentioned in the statement of the 
rejection on page 3. To the extent that the rejection does apply to claim 11, 
however, the rejection is respectfully traversed on the grounds that the Nixon 
and Grittke references, whether considered individually or in any reasonable 
combination, fail to disclose or suggest: 

authentication of the software module being transferred to the field device 

by a function-block shell in the field device. 

According to page 9 of the Official Action, Nixon teaches transmitting a 
software module to field devices, but does not mention checking the authenticity 
explicitly. However, Grittke is said to teach checking the authenticity of software 
being transferred to field device, because paragraph [0033] of Grittke mentions 
that: 

Following the actuation of the switch 14, access to the field devices 
2, 3, 4, or the field bus adapter 7, is possible for a certain time span. 
This safety level already offers a certain amount of protection 
against unauthorized accessing of the devices 2, 3, 4, 7. For 
instance, it is not out of the question that a plurality of accessings of 
the device might occur following actuation of the switch 14 and that 
perhaps one of them might be unauthorized. Therefore, in order to 
block unauthorized accessing, only the first accessing, or only one 
connection, is allowed after the actuation of the switch, while all 
additional accessing/connection attempts are rejected. 

This application of Grittke is incorrect for two reasons: 

a. The switch 14 that is closed to prevent access is in the field-bus 

adapter 7 between the fieldbus 5 and the adapter unit 8, and 

therefore cannot possibly be operated by a function-block shell in 

the field devices 2, 3, 4 of Grittke (see Fig. 1 ), and 
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b. Closing a switch to prevent multiple accesses, as taught by Grittke, 
is not the same as checking authenticity, as claimed (much less 
having a function-block shell in the field device check authenticity). 

By closing the switch 14 after the first access, Grittke merely solves the problem 
that subsequent accesses are more likely to be unauthorized accesses. Grittke 
does not, however, prevent (or even attempt to prevent) forged software from 
being transferred by a clever forger during the first access. Once forged software 
passes through the switch 14, there is nothing in Grittke to prevent the forged 
software from being installed in any of the field devices 2, 3, or 4. 

It is noted that not any software modules can be authenticated. In general, 
some sort of signature or processing is required before any piece of software or 
file can be authenticated. In the case of the claimed invention, authentication by 
application shells in the field devices is made possible by providing the software 
module in the form of a DTM according to FDT-Specifications. Grittke does not 
use this approach. Instead, Grittke controls transfer of software to the field 
devices by controlling the field bus adapter 7, which controls access to the 
fieldbus 5 and is not part of any field device. Grittke does so not only by 
controlling the number accesses, as in the passage quoted by the Examiner, but 
also by password protection of the adapter, as explained in paragraph [0014] 
of the Grittke publication. In addition, or alternatively to limiting the number of 
accesses, Grittke may also provide for counting and reporting the number of 
accesses to the field devices, as explained in paragraph [001 5]. However, none 
of these security measures taught by Grittke involves using a function- 
block shell in the field device to authenticate software modules being 
transferred thereto . Instead, they all involve controlling access to the fieldbus, 
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and not to any particular field device . Therefore, Grittke does not teach the 
features of claim 1 1 . 

Since the Grittke application does not disclose or suggest having 
application shells in field devices check the authenticity of software modules 
being transferred to the field devices, Grittke does not make up for the 
deficiencies of the Nixon application, which provides no security at all for the 
software installation. As a result, the Nixon and Grittke publications do not render 
obvious the features of claim 1 1 , which are now included in amended claims 6 
and 13. 

3. Rejection of Claim 13 Under 35 USC §1 03(a) in view of U.S. Patent Publication 
Nos. 2002/0077711 (Nixon) and 2005/0033886 (Grittke), and U.S. Patent No. 
5,909,368 (Nixon368) 

This rejection has also been rendered moot by the amendment of claim 13 
to include the limitations of claims 7 and 1 1 . 

4. Rejection of Claim 7 Under 35 USC §1 03(a) in view of U.S. Patent Publication 
Nos. 2002/0077711 (Nixon), 2005/0033886 (Grittke), and 2005/0046838 
(Wittmer) [actually, the body of the rejection refers to U.S. Patent No. 5,960,214 
(Sharpe)l 

This rejection is respectfully traversed, in so far as it may prospectively be 
applied to amended claims 6 and 13, on the grounds that Nixon, Grittke, and 
Sharpe (or Wittmer) fail to disclose or suggest, whether considered individually 
or in any reasonable combination, a method for transferring software code from 
a control unit to a field device in which: 

a function-block shell in the field device authenticates software modules 

being transferred thereto, and 
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the software modules are DTM software modules provided according to 
FDT-Specifications (which is what enables authentication of the software 
modules by the application shell). 
As explained above, Nixon does not secure transfer of software modules, while 
Grittke takes the approach of limiting access to the fieldbus (via an access device 
7) rather than having individual field devices authenticate software being 
transferred thereto. 

These deficiencies are not made up for by the Sharpe publication, which 
teaches smart field devices with management software, but not use of the 
management software to authenticate software being transferred thereto. To the 
contrary, in the proposed combination, since Grittke teaches use of the fieldbus 
access device for security, there does not appear to be any obvious need for 
additional security at the field device level. 

As to Wittmer, which appears to have been cited in error, it is noted for the 
record that this publication has absolutely nothing to do with software module 
transfer or authentication. 

Finally, with respect to amended claim 1 3, it is respectfully noted that while 
Nixon368 briefly mentions a security function in a process control environment, 
there is no suggestion whatsoever that this security function involves having 
the application shell of a field device authenticate DTM software modules being 
transferred thereto , as claimed. 

Accordingly, none of the references of record, considered in any 
reasonable combination, discloses or suggests the currently claimed invention, 
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and withdrawal of each of the rejections under 35 USC §1 03(a) is respectfully 
requested. 



Having thus overcome each of the rejections made in the Official Action, 
expedited passage of the application to issue is requested. 

Respectfully submitted, 
BACON & THOMAS, PLLC 
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